Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-040.txt

Text File | 1992-11-18 | 30.1 KB | 829 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 03 Apr 92       Volume 1 : Issue 40

Today's Topics:

    Absolutely the fastest animation possible?
    Saving compressed 32-bit PICTs.
    ?Changing In-Use File names (etc.)?
    FPU instructions
    Changing Fonts in Dialogs


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

Subject: Absolutely the fastest animation possible?
From: [e-mail] (Tony Cooper)
Date: Wed, 26 Feb 92 02:39:35 GMT
Organization: Applied Mathematics Group D.S.I.R.


What is the best way to display animation on the screen as fast as possible.
Assuming a NUBUS video card I have some ideas:

1) Turn off interrupts except the video card interrupt. Not sure how to do
this but I'm sure it is easy.

2) Copy images from RAM to the video card using one of
    a) CopyBits
    b) A single purpose version of CopyBits that is faster than Apple's
    c) Address the NUBUS card directly (maybe block transfer is possible)
    d) Some other method

3) Store the images in RAM on the NUBUS card itself if available.

Does anyone have any better suggestions? Which is faster out of a) to d)?
If c) is faster, how do you do it? It only has to work on my Mac. Ideally
I'd like to do 67 frames per second and I want the pictures to be as big
as possible. At least 512x512 pixels of 8 bit colour. (Now you know why I
want it to be as fast as possible).

Thanks
Tony Cooper
[e-mail]



- -------------------------

From: [e-mail] (Ray Fischer)
Subject:  Absolutely the fastest animation possible?
Date: 26 Feb 92 09:12:57 GMT
Organization: Computer Science Department, Stanford University.

[e-mail] writes ...
>What is the best way to display animation on the screen as fast as possible.
>
>1) Turn off interrupts except the video card interrupt. Not sure how to do
>this but I'm sure it is easy.

This may cause you problems.  Even if it doesn't, I'm not sure it would
make a big difference. (couple percent?)

>2) Copy images from RAM to the video card using one of
>    a) CopyBits

CopyBits will take care of alignment, but is fastest if both images are
long word aligned and no color conversion gets done (i.e., both have
the same color pallette)

>    b) A single purpose version of CopyBits that is faster than Apple's
>    c) Address the NUBUS card directly (maybe block transfer is possible)

These two are likely to be the same solution.  Not a trivial undertaking.

>Does anyone have any better suggestions? Which is faster out of a) to d)?
>If c) is faster, how do you do it? It only has to work on my Mac. Ideally
>I'd like to do 67 frames per second and I want the pictures to be as big
>as possible. At least 512x512 pixels of 8 bit colour. (Now you know why I
>want it to be as fast as possible).

512*512*67 works out to almost 17MB/sec.  For most Macs this is out
of the question.  Considering that a IIcx has a clock rate of 16MHz
and every instruction takes several clocks, it just doesn't work.
This is one 32-bit word read or written every 115ns.  I don't know,
but I doubt many Mac video cards or CPU's can provide this kind of
performance.

The fastest way to get data onto the screen is find the address of the
screen buffer, then write an assembler routine to do block moves.  Loop
unrolling is a must.  If you get this far, then you can get some idea
of how fast you can transfer to the screen, and then decide where to
make the tradeoffs.

Ray
[e-mail]



- -------------------------

From: [e-mail] (Lincoln Stein)
Subject:  Absolutely the fastest animation possible?
Date: 26 Feb 92 12:31:09 GMT
Organization: Massachusetts Institute of Technology

>>Does anyone have any better suggestions? Which is faster out of a) to d)?
>>If c) is faster, how do you do it? It only has to work on my Mac. Ideally
>>I'd like to do 67 frames per second and I want the pictures to be as big
>>as possible. At least 512x512 pixels of 8 bit colour. (Now you know why I
>>want it to be as fast as possible).
>
>512*512*67 works out to almost 17MB/sec.  For most Macs this is out
>of the question.  Considering that a IIcx has a clock rate of 16MHz
>and every instruction takes several clocks, it just doesn't work.
>This is one 32-bit word read or written every 115ns.  I don't know,
>but I doubt many Mac video cards or CPU's can provide this kind of
>performance.

NuBus on all machines up to the FX is limited to 10MB/sec (I think).  The
Quadras can manage 20 MB/sec, but only on card-to-card transfers.
Motherboard-to-card is still limited to 10MB/sec due to a limitation of
Apple's NuBus controller chip.  17MB/sec is too fast.

==============================================================================
Lincoln D. Stein            Brigham & Women's Hospital
[e-mail]            Boston, MA
==============================================================================




- -------------------------

From: [e-mail] (Stephen Uitti)
Subject:  Absolutely the fastest animation possible?
Date: 26 Feb 92 19:54:46 GMT
Organization: Interactive Systems, Cambridge, MA 02138-5302

>>512*512*67 works out to almost 17MB/sec.

>NuBus on all machines up to the FX is limited to 10MB/sec (I think).

If you can't do the whole job, do less.  So... if you have it all
in memory to begin with, maybe you can compute just which pixels
have changed in advance, and update only those.  Maybe extent
lists, similar to run length encoding is the answer.  If it turns
out that you only have to update half of the pixels, you may be
able to increase the speed by enough.  Of course, it may take
more than one frame to update the whole screen for a sudden
screen change.

Stephen.
[e-mail]



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Absolutely the fastest animation possible?
Date: 26 Feb 92 18:48:19 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Tony Cooper) writes:

   1) Turn off interrupts except the video card interrupt. Not sure how to do
   this but I'm sure it is easy.

What good would this do ? This is generally done on DOS machines,
but is totally unacceptable on a mac, since the mouse will freeze
and become jerky (and the keyboard is not heeded !)

   2) Copy images from RAM to the video card using one of
       a) CopyBits

Yes ! This also works very well with accellerated cards. It
is guaranteed to work with all future cards/systems/etc

       b) A single purpose version of CopyBits that is faster than Apple's

1) It's hard to beat CopyBits if you know how to handle CopyBits
right. Besides, try and make your CopyBits work with accelerated
cards, 24bit cards on 24bit machines, various screen depths,
windows spanning screens, ...

       c) Address the NUBUS card directly (maybe block transfer is possible)

No Block Transfers under program control.

   3) Store the images in RAM on the NUBUS card itself if available.

Only on accellerated cards. You do this by creating an offscreen
GWorld (which will be on the card if the right flags are set)
and draw your picture into that GWorld. Transfers within the card
will be fast, but only for accellerated cards (won't matter much
on other cards anyway...)

   as possible. At least 512x512 pixels of 8 bit colour. (Now you know why I
   want it to be as fast as possible).

Keep dreaming. That's 256 kByte, 67 times/second > 17MB/second. Last
I looked, Mac NuBus couldn't handle that, doing longword transfers,
what with re-synching and everything.

Not to mention; where do you get those 17 MB of image data from ?

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (R.W. Kentridge)
Subject:  Absolutely the fastest animation possible?
Date: 27 Feb 92 15:57:41 GMT
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU.


  512*512*67 = 17563648 or about 17.5 million byte moves per second.
  Isn't a 680x0 going to have a bit of trouble with this?

  But you can still copy about twice as fast as CopyBits if you know
  that your source and destination Rects are the same size and the
  same depth and if you ignore (or avoid) having any incomplete bytes
  at Rect edges and then you do the copy loop in assembler (if the whole
  rect can be moved with MOVE.Ls then this will be fastest) and you don't
  support multiple screens and so on.  Still wont do 17.5 million bytes
  a sec though :-(
                    cheers,
                         bob



- -------------------------

From: [e-mail] (Jim Bailey)
Subject:  Absolutely the fastest animation possible?
Organization: Lexicon, Inc., Waltham, MA
Date: Thu, 27 Feb 1992 19:14:24 GMT

In article <[e-mail]> [e-mail] (Lincoln Stein) writes:

   NuBus on all machines up to the FX is limited to 10MB/sec (I think).  The
   Quadras can manage 20 MB/sec, but only on card-to-card transfers.
   Motherboard-to-card is still limited to 10MB/sec due to a limitation of
   Apple's NuBus controller chip.  17MB/sec is too fast.

   ==============================================================================
   Lincoln D. Stein            Brigham & Women's Hospital
   [e-mail]            Boston, MA
   ==============================================================================

The theoretical limit should be closer to 40MB/sec, ( 37 MB/sec I
think ).  Are you saying that Apple's NuBus implementation is that
limited?

Jim
--
"The Beatles were elevator music in my lifetime 'Yummy Yummy Yummy (I've Got
Love In My Tummy)' had more impact on me" -- Michael Stipe of R.E.M.
[e-mail]



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Absolutely the fastest animation possible?
Date: 2 Mar 92 21:27:06 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Lincoln Stein) writes:
>
> >>Does anyone have any better suggestions? Which is faster out of a) to d)?
> >>If c) is faster, how do you do it? It only has to work on my Mac. Ideally
> >>I'd like to do 67 frames per second and I want the pictures to be as big
> >>as possible. At least 512x512 pixels of 8 bit colour. (Now you know why I
> >>want it to be as fast as possible).
> >
> >512*512*67 works out to almost 17MB/sec.  For most Macs this is out
> >of the question.  Considering that a IIcx has a clock rate of 16MHz
> >and every instruction takes several clocks, it just doesn't work.
> >This is one 32-bit word read or written every 115ns.  I don't know,
> >but I doubt many Mac video cards or CPU's can provide this kind of
> >performance.
>
> NuBus on all machines up to the FX is limited to 10MB/sec (I think).  The
> Quadras can manage 20 MB/sec, but only on card-to-card transfers.
> Motherboard-to-card is still limited to 10MB/sec due to a limitation of
> Apple's NuBus controller chip.  17MB/sec is too fast.

The NuBus runs at 10 MHz, which is 10 million cycles per second; however, up
to four bytes can be transferred in each cycle, because the bus is 32 bits
wide.  Because of arbitration cycles, etc, you don't get 100% throughput, so
the maximum transfer speed is on the order of 37 megabytes/sec with tuned
code.  However, this doesn't really happen on Macs, for the following reasons:

 - Video cards can't necessarily process a transaction in one cycle.
 - Macs can't keep up that kind of transfer rate
 - Because the NuBus runs at 10 MHz/sec, but Mac processors run at rates which
   are not necessarily even divisors of that rate, the Mac often has to wait for
   a moment to synchronize the data transfer.  This is a larger problem on
   faster Macs, (the fx may have to wait up to 3 clock cycles to synchronize).

Best of luck,
Tim Dierks
MacDTS, but I speak for myself



---------------------------

From: [e-mail] (Jesse Jones)
Subject: Saving compressed 32-bit PICTs.
Organization: University of Washington, Seattle
Date: Wed, 26 Feb 1992 22:11:31 GMT


   I'm having some trouble saving a 24-bit image as a PICT. I'm trying
to build the PICT without going through QuickDraw. When I use no packing
everything works fine. However, when I use pack type 4 PhotoShop hangs
when I try to open the PICT. I've compared my PICT file with one
generated by PhotoShop and they look identical up to the pixData. I've
also examined my code to pack the scan lines and am pretty sure it's
OK.

   IM 6 is fairly terse but I think I understand how pack type 4 works:
each component of a scan line is packed using PackBits. First red, then
green, and finally blue. Each packed component is preceded by either a
byte or a word for the byte count. This looks perfectly straightforward.
Is there something I missed? Does IM leave anything out? Any help would
be greatly appreciated.

  --Jesse




- -------------------------

From: [e-mail] (Ralph Sutherland)
Subject:  Saving compressed 32-bit PICTs.
Organization: Computer Services Centre, Australian National University
Date: Thu, 27 Feb 92 04:58:20 GMT


[e-mail] (Jesse Jones) wrote:

        .
        .
        .

>   IM 6 is fairly terse but I think I understand how pack type 4 works:
>each component of a scan line is packed using PackBits. First red, then
>green, and finally blue. Each packed component is preceded by either a

Did you forget the alpha channel or are only 24 of the 32 bits saved in
type 4 packing?

cheers
ralph

--
- -- Ralph S. Sutherland      Mount Stromlo & Siding Spring Observatories.
- -- [e-mail]  The Australian National University.
- -- [e-mail] --------------------------------------------



- -------------------------

From: [e-mail] (Tim Dierks, ToyMeister, Cray abuser)
Subject:  Saving compressed 32-bit PICTs.
Date: 2 Mar 92 21:06:48 GMT
Organization: MacDTS, Apple Computer

In article <[e-mail]>, [e-mail] (Jesse Jones) writes:
>
>
>    I'm having some trouble saving a 24-bit image as a PICT. I'm trying
> to build the PICT without going through QuickDraw. When I use no packing
> everything works fine. However, when I use pack type 4 PhotoShop hangs
> when I try to open the PICT. I've compared my PICT file with one
> generated by PhotoShop and they look identical up to the pixData. I've
> also examined my code to pack the scan lines and am pretty sure it's
> OK.
>
>    IM 6 is fairly terse but I think I understand how pack type 4 works:
> each component of a scan line is packed using PackBits. First red, then
> green, and finally blue. Each packed component is preceded by either a
> byte or a word for the byte count. This looks perfectly straightforward.
> Is there something I missed? Does IM leave anything out? Any help would
> be greatly appreciated.

Actually, there's only one byte count, which counts the bytes for all three
components.  This isn't incredibly obvious by the description, but can be
seen in the format description (in Courier, near the top of page IV-17-22).

If packType > 2 (packed) then
..
    Each scan line consists of [byteCount] [data].

Implying that byte counts are line-based, not component-based.  I build an
array with all three components, packed together, then PackBits the whole
thing, then write the count, then the entire packed array.

Tim Dierks
MacDTS, but I speak for myself



---------------------------

From: Bill Williams
Subject: ?Changing In-Use File names (etc.)?
Date: 27 Feb 92 18:13:26 GMT

Netters,

     I have written a lab data collection/automation program that writes data
periodically to a file.  The technician in my lab noted the other night that a
file that the program was writing to didn't follow our lab naming/folder
conventions, so she got into the finder (system 7), moved the file into the
proper folder, and renamed it!  But the file was still in use!!!

    Questions:

    1.  Shouldn't the fact that the file is in use be discovered by the
Finder and disallowed??!!??

    2.  What kinds of trouble can be caused by renaming a file while it's
in use?  It seems like it could cause all kinds of problems; in my program, for
example, the name of the file is displayed (dimmed) in the File menu replacing
the "open" item, so the user can figure out what's going on.

    3.  Is there some way for my program to "lock" the filename, so that
the Finder won't allow it to be moved or changed?


            -Bill Williams
            -St. Mary's College of Maryland



- -------------------------

From: [e-mail] (JohnC)
Subject:  ?Changing In-Use File names (etc.)?
Date: 27 Feb 92 18:54:36 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> Bill Williams writes:
>     I have written a lab data collection/automation program that writes data
>periodically to a file.  The technician in my lab noted the other night that
>a file that the program was writing to didn't follow our lab naming/folder
>conventions, so she got into the finder (system 7), moved the file into the
>proper folder, and renamed it!  But the file was still in use!!!
>
>    Questions:
>
>    1.  Shouldn't the fact that the file is in use be discovered by the
>Finder and disallowed??!!??

Why?  This is the documented behavior of _Rename.  While a file is open, it
is referred to by a path reference number, not by name, so this really
shouldn't cause any problems.

>    2.  What kinds of trouble can be caused by renaming a file while it's
>in use?  It seems like it could cause all kinds of problems; in my program,
>for example, the name of the file is displayed (dimmed) in the File menu
>replacing the "open" item, so the user can figure out what's going on.

You should modify your program to check the name periodically, in order to
update the menu item if the file name has changed.

>    3.  Is there some way for my program to "lock" the filename, so that
>the Finder won't allow it to be moved or changed?

I don't believe this is possible on non-shared volumes, although on shared
volumes there is a check-box to prevent the object (file or folder) from
being moved or renamed.


--
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637



- -------------------------

From: [e-mail] (Michael Hecht)
Subject:  ?Changing In-Use File names (etc.)?
Date: 2 Mar 92 15:54:27 GMT
Organization: SAS Institute Inc.

In article <[e-mail]>, Bill Williams writes:
>     3.  Is there some way for my program to "lock" the filename, so that
> the Finder won't allow it to be moved or changed?

You can call SetFLock on the file to lock it while you're writing to it.
This won't prevent it from being changed, but it will slow the user down
if they try to open it, for example. Before you close it, call RstFLock.

You can prevent the file from being renamed by setting its System bit.

You could also intially name the file some thing like "Whatever (in use)"
while you're writing to it. Then, rename it to the correct name after you
close it.

You could also make the file invisible while you have it open.

--Michael

PS: Nice return address :-)

=======================================================================
Michael P. Hecht                 | Internet:  [e-mail]
SAS Institute Inc.; Cary, NC USA | AppleLink: SAS.HECHT



---------------------------

From: [e-mail] (Matthew Hall)
Subject: FPU instructions
Date: 28 Feb 92 02:07:26 GMT
Organization: Oberlin College Computer Science

Hello -
    I am trying to write a unit that will read a typed in string
of a mathematical function - translate it into RPN, and (here's the
tricky part) Compile it into FPU code.  That is, at runtime, create a subroutine in
the heap that when I  (JSR (funcptr)) it pops the return value into my
stack.
    Okay, everything is easy so far.  I got the RPN, I got the
subroutine to move the data to return nicely with a number on the
stack.  The problem is - I'm not sure of the FPU instructions.  By
poking around with macsbug, I figured that an FPU opcode looks
something like this

  bits 24 - 31  Always F2
  bits 22 - 23  ?
  bits 16 - 21  Addressing mode and reggister for CPU addressing
  bits 13 - 15  000 for addressing FPU regs
        010 for CPU reg as source
        011 for CPU register as destination
  bits 10 - 12  Destination FPU reg, or size of data for CPU reg
          operations (What is .P the size of?)
  bits 7  - 9   Another FPU reg
  bits 0  - 6   The Instruction (00 - move,  23 - multiply I guess)

Now, I don't have access to any FPU manuals.  I think I have the right
idea - I just want to be sure that I have this right before I start
programming a mini assembler (I only have THINK Pascal, so writing
this will be a bit tricky)  Plus, there are some missing bits.  Could
some kind generous soul with a 68881/2 manual pleas help me.

(Oh yeah, what's the difference between a 68881 and an '82.  Always
been curious)

Thanks -
matt hall

Alt. Mail address - [e-mail]


--

<<[e-mail] OR
<<[e-mail]

This is just a beta version signature



- -------------------------

From: [e-mail] (P. Hawthorne)
Subject:  FPU instructions
Date: 29 Feb 92 09:55:03 GMT
Organization: Reed College, Portland OR


  [e-mail] (Matthew Hall) writes:
: I am trying to write a unit that will read a typed in string of
: a mathematical function - translate it into RPN, and (here's the
: tricky part) Compile it into FPU code.

  If you want concurrent execution, you need the timing in the Motorola
manuals, but as far as simple operations, you can basically have a go at
the instruction formats in ResEdit with the CODE resource editor from
ftp.apple.com and get simple arithmetic functions. That's how I've learned.
Big hint, any similarity from instruction to instruction is pure luck, and
the bits you don't know about can hurt you. Rounding mode is subtle.
  Getting the addressing modes right is the worst part, after assembling
the branches and jumps. There's a fast trick for FPU divide by two.
  In a perfect world, you would get the manuals. I borrowed mine from a
friend, and found myself much, much more expressive. Get in touch with me
and I'll fax you some instruction formats, if you're interested. I'm
interested in how you handled operator precedence in postfix translation,
since I'm just using a 2D array.

  There are eight 80-bit extended precision registers, but Think Pascal
uses all of them. FP0, FP1, and FP2 are not relied upon by Think Pascal to
hold values between Pascal terms, so they're basically available. From
interrupts, all bets are off as to what condition the registers are in. All
of the addressing modes are there, but they are done by the 680n0.
  All operations are performed at extended precision even if conversion is
required, which basically means use native extended precision if you're a
speed freak, and it sounds like you are. I know I am. ;-}
  If you're really hell bent on end run performance, you can interleave
fixed point and FPU instructions so that you get both processors going at
once. I did this with for an adaptive Bezier curve subdivision routine,
which consumed half of the application run time, and got an improvement in
response time. Sure it took me forever, but it is a strong performance
factor for machines blessed with 6888n FPUs.
  Crying shame that the Quadras are lobotomized in this respect.

 "Good news: we've got TV bandwidth and are moving to consumer electronics,
  the bad: we left out transcendentals and are going RISC. Get over it."
                          -- Apple Computer, Inc. 1992
  Theus [e-mail] [phone]




- -------------------------

From: [e-mail] (Ray Fischer)
Subject:  FPU instructions
Organization: Computer Science Department, Stanford University.
Date: Sun, 1 Mar 1992 22:35:54 GMT

[e-mail] (Matthew Hall) writes ...
>    Okay, everything is easy so far.  I got the RPN, I got the
>subroutine to move the data to return nicely with a number on the
>stack.  The problem is - I'm not sure of the FPU instructions.  By
>poking around with macsbug, I figured that an FPU opcode looks
>something like this
>
>  bits 24 - 31  Always F2
>  bits 22 - 23  zero
>  bits 16 - 21  Addressing mode and reggister for CPU addressing
   bit  15       zero
>  bits 14       register(0) or memory(1) for source operand
   bit  13       zero usually, 1 for FMOVE from FPn
>  bits 10 - 12  Source specifier (expect for FMOVE from FPn,
        then dest format)
>  bits 7  - 9   dest reg, except FMOVE from FPn, then source reg
>  bits 0  - 6   The Instruction (00 - move,  23 - multiply I guess)
        Correct, except k-factor with FMOVE from FPn which
        involves packed decimal formats
>
>Now, I don't have access to any FPU manuals.  I think I have the right

Get one.  The 68882 is complex with options for handling various
number formats and exception conditions, in addition to several
instructions.  Prentice Hall ISBN 0-13-567009-8

>(Oh yeah, what's the difference between a 68881 and an '82.  Always
>been curious)

The 68882 has the capability of doing transfers to/from memory while
the APU is doing computation.  Thus, the 68882 can load one register
while doing math with a different register.  The 68881, in general,
can't do this.

Ray
[e-mail]



---------------------------

Subject: Changing Fonts in Dialogs
From: [e-mail]
Date: 26 Feb 92 15:46:02 GMT
Organization: Amherst College, Amherst, MA.

  I'm writing an application which has to use some funny symbols in dialog
boxes.  I have implemented this by creating my own font, and then calling
SetDAFont to have my font used in the dialog boxes.  The problem with this
is that my font gets used in other dialog boxes too--for example, sometimes
if a desk accessory is opened while my program is running, it ends up using
my font.
  I can think of a number of ways to avoid this problem, but I'm wondering
if there is a "recommended" way of doing it.  Should I call SetDAFont right
before I create a dialog, and then call it again as soon as I'm done with
the dialog to set the DA Font back to the system font?  Can I even change
the DA Font back to the system font once I have created the dialog (but
before I'm done with it)?  (In other words, is the DA Font only looked at
by GetNewDialog?)  Should I forget about SetDAFont altogether and
just create the dialog record and then change its font before I show it?
(If so, do I change the txFont field of the dialog's grafport, or its
TextEdit record, or both?  My guess is that the txFont field of the grafport
will affect static text items and the TextEdit record will affect edit text
items, but I haven't tried it.  Can I even make these two different if I want
to?)
  Please e-mail responses, since I don't read this newsgroup regularly.
Thanks.
  Dan Velleman
  Dept. of Math & CS
  Amherst College
  [e-mail]




---------------------------

From: [e-mail] (Douglas Bitting)
Subject: A5 and Completion Routines
Organization: You gotta be kidding me!
Date: Sat, 29 Feb 1992 21:29:31 GMT


Hi.  I am having trouble setting up A5 for use within a completion
routine.  I have been pulling my hair out over this for the last 4
hours (I don't give up easily, do I?).  Instead of me trying to
explain everything to you, I'll show you the code (it's reasonably
short) that is bothering me:

- --snip here----
static    short    done;

// As per TechNote #180
MPPPBPtr
GetMPPPBPtr(void)
    = 0x2008;                // MOVE.L    A0,D0

// Again, follows closely from TN#180
pascal void
SetDone(void)
{
    long        tmpA5;
    MPPPBPtr    whee;
    MPPParamBlock    mp;

    whee = GetMPPPBPtr();
    mp = *whee;

    tmpA5 = SetA5(mp.NBP.userData);
    done = 1;            // to flag PLookup() is done
    SetA5(tmpA5);
}

void
FindMe (char *what, char *name)
{
    [...]

    mp.NBP.ioCompletion = SetDone;
    mp.NBP.interval = 1;
    mp.NBP.count = 4;
    mp.NBP.userData = SetCurrentA5();

    [...Don't worry, I set up the rest of mp...]

    if (CheckError(PLookupName(&mp, true))) {

    [...]

    while (!done) {
        WaitNextEvent(everyEvent, &blah, 5L, aRgn); // sleep
    }

    done = 0;

    [...]
}
- --snip here----

I checked with MacsBug and it is definitely getting to the completion
routine, but the value that is found in mp.NBP.userData is not even
close to what A5 should be set to.  So, one question would be "Does
mp.NBP.userData get clobbered by PLookupName()?" ... the next would if
"If not, then what the heck am I doing wrong?"

Thanks!
--Doug
--
 ...Doug Bitting... || "But the wisdom that comes from heaven is first
                    ||  of all pure; then peace loving, considerate,
[e-mail] ||  submissive, full of mercy, and good fruit,
[e-mail]  ||  impartial and sincere."  -- James 3:17
--
--
A crisis is when you can't say Let's forget the whole thing.



- -------------------------

From: [e-mail] (P. Hawthorne)
Subject:  A5 and Completion Routines
Date: 1 Mar 92 12:07:08 GMT
Organization: Reed College, Portland OR


  [e-mail] (Doug